ECTA-CEFIC Guidelines For Standardized Coding Of Transport Events

ECTA CODES
ISSUE 3 (corrected version): April 2017

Disclaimer

This document is intended for information only and sets out the elements of data structure and standard coding for the reporting of transport events. The information, specifications, methods and recommendations contained in these guidelines are provided in good faith and are believed to be accurate and reliable, but may well be incomplete and/or not applicable to all conditions or situations that may exist or occur.

No representation, guarantee or warranty is made as to accuracy, reliability or completeness of said information, specifications, methods and recommendations or that the application or use of any of the same will avoid hazards, accidents, loss, damage to property or injury to persons of any kind or that the same will not infringe patents of others or give desired results. Readers are cautioned to satisfy themselves as to the suitability of said information, specifications, methods and recommendations for the purposes intended.

Wherever the Guidelines refer to a specific reporting system, it is understood that parties may, even if this is not explicitly mentioned, also choose to rely on equivalent systems or to set up and to monitor transport events in their own way. Nothing in the Guidelines shall be construed as restricting the parties’ ability to adopt another system or as a limitation to the quality and variety of services offered.

The Guidelines do not contain any restrictions on pricing or terms and conditions. No responsibility will be assumed by the participating associations, Cefic and ECTA, in relation to the information contained in these guidelines.

Disclaimer
1. Introduction
2. Objectives
3. Scope of the Standard
4. Structure of the Code String for Transport Events
5. Description of the Code Categories
6. Coding Data Specifications
7. Means of Communication

1. Introduction

Many companies in the chemical industry are measuring the transport performance of their Logistic Service Providers (LSP’s) through data collection. LSP’s also measure their internal performance.

For the greater part of this data collection, the chemical industry relies on input from their carriers and expects this reporting to be done between them on the basis of their contractual agreements and bilateral systems. As a consequence, carriers serving several chemical companies are facing different reporting systems for the same transport events that occur.

The reporting covers the transport orders which are deviating in their execution from the customer’s requirements. The shipper wishes to be informed about these transport events and backgrounds.

The data collection of such transport events is then used to analyse the carrier’s performance and provide information which allows improvement via collaborative efforts between the shipper and the carrier.

A working party under the joint umbrella of Cefic and ECTA elaborated in 2002 a “Guideline on Standardized delivery performance measurement”. A matrix with reporting codes, called “ECTA codes” was introduced and recommendations on data collection were formulated.

In 2007 a revision of the 2002 guideline was initiated in order to improve the precision of the reporting, to clarify interpretation of the standard codes and to include some additional options reflecting intermodality in transports and IT connectivity between haulier and shipper. In the 2017 document revision, an extra ‘Date & Time’ code was added allowing to categorize early deliveries while some minor textual corrections were made improving the overall accuracy of the document.

This document replaces the ECTA-Cefic Guideline of 2002 and proposes the application of standard coding and data structure for reporting of transport events in chemical transports. This does not restrict the freedom of individual companies to maintain or create their own reporting systems.

2. Objectives

The main objective of these guidelines is to introduce reporting of events, which have occurred during the execution of a transport order, by using ECTA codes so as to enable a standardized event coding. This should lead to a system which can be used by a wide range of companies.

Advantages of using ECTA codes:

Provides a common base for mutual understanding
Simplifies reporting systems for the same transport events
Optimizes time and effort spent on collection, transmission and processing of data
Allows to identify trends
Allows to calculate frequencies of specific events
Increases reliability and accuracy of information
Increases the opportunity for automatic collection and exchange of information.
Enables the identification of areas of improvement and weaknesses and provides a platform for continuous improvement.

3. Scope of the Standard

There are three types of events related to a transport order, which will trigger communication between carrier and shipper:

Operational events
Any deviation in the requirements related to one specific order in a specific stage of execution. Most of these events are communicated by the driver or staff members in the carrier’s planning department who will register the event in the system. The information is passed to the shipper’s system and used by the shipper’s logistics department.
Complaints
The shipper’s customers report a failure to the shipper’s logistics department. This will trigger a joint Root Cause Investigation that will allow the shipper to respond to his customer on the complaint.
Safety Incidents
A safety incident leads to a further investigation under the supervision of the shipper’s SHE department.

For reporting of operational events, a structured string of codes as determined in these guidelines is sufficient. The event codes need to be easy to understand and straightforward. They will be used by planners in the transactional system and shouldn’t take long to fill in. It is the registration of an occurrence, with a simple indication of an “apparent reason” for the reported event.

For customer complaints it is likely that additional specific information will be required. The reporting system allows for a communication based on a customer complaint, which can effectively be registered at a later date than the fulfilment of the order. It is indeed possible that customer complaints are not immediately registered by the carrier since this information may reach him only at a later stage or via his shipper.

Out of the scope of this guideline is further investigation (e.g. through root cause analysis) of serious complaints and safety incidents.

The reporting is by exception: It is only to be used for transport orders with non conformance events. The apparent reason for the event should be reported. For instance: a late delivery due to traffic congestion.

In case multiple events occur with one single shipment, this will result in several strings of information (one string of information per event).

Shippers operating integrated system-to-system connections to their main hauliers may wish to evolve the reporting standards into a full reporting of transport orders. Since system interconnectivity is in most of these cases present, the event reporting is fully automated between the main haulier and the shipper. In such an IT environment, a full reporting even on the vast majority of transport orders which were successfully executed without any transport event becomes possible due to this automation level. However, when manual entry is required by the carriers directly into the shippers system (e.g. in an internet web interface) the reporting of events as a reporting by exception is highly recommended. Full reporting would in such cases require an excessive administrative and non-productive effort from the carriers. These Guidelines are based on the general principle that the absence of reporting means there are no transport events to report.

4. Structure of the Code String for Transport Events

The event is transmitted in a code string that describes information related to: what, under whose control, which transport mode, what type of order, when and why (=the apparent reason). The structure of the code string allows quantifying information for data mining according to code categories.

See also: Annex 1: Matrix of the code categories The following code categories have been defined:

What is the event linked to?
Under whose control did it happen?
Which mode of transport was used?
Was it a normal order or a rush order?
When did the event occur?
Is there a customer complaint?
Why did it occur? (apparent reason of the event)

For proper utilisation of the system, the use of the codes as described and as numbered in the matrix is required. Each company can adapt their entry system to suit their needs, e.g. entry of information in a different order, but the IT code string is standardized.

5. Description of the Code Categories

5.1 What is the event linked to?

This code category defines the type of event that took place. It describes the deviation from the customer’s requirements. This category is coded as follows:

DATE & TIME (CODE DT or ET)
- DT (delay in date and time): in case of a late arrival
- ET (early in date and time): in case of a too early arrival
  Examples of events leading to reporting under this code: the vehicle arrived late at the loading point or at the delivery point due to traffic congestion; the surveyor was not timely present on arrival; strong winds prevented discharge at agreed time; delay occurred at the previous unloading site. The vehicle arrived early at the delivery point given there was less than expected traffic; a previous delivery got cancelled; the arrival of the delivery got planned earlier than foreseen.
EQUIPMENT (CODE EQ)
Unsuitable or unfit equipment either from the shipper, the final customer or the haulier or his transport subcontractors. Most of the events reported under equipment are likely to be equipment breakdowns or equipment not meeting specifications.
Examples: the carrier did not bring the specified type of couplings; the tank wagon was refused because of non authorized previous cargo; the unloading equipment was unsafe; the seal was compromised; the unloading tank was not big enough to accept the delivery; breakdown of the fork lift.
PRODUCT (CODE PR)
Related to the quality or condition of the product itself.
Examples: the cargo was not presented at correct temperature; the delivered packaging was damaged; part of the load was stolen.
DOCUMENTATION/ORDER PROCESS (CODE DO)
Related to the transport documents or to customs documents or to the order process.
Examples: the customs documents went missing; incorrect documents were issued; EDI message failed.
SHE INCIDENT (CODE SH)
All Safety Health Environment (SHE) related incidents are reported within this category.
Examples: PPE was missing; at delivery point a near miss took place; an operator at the unloading point drove with a forklift by accident against the driver; wrong behaviour of driver or of the operator.

5.2 Under whose control did it happen?

This category describes who is in control when the reported event happened: either directly or through his appointed third parties (examples: surveyors, rail operators, shipping lines). Since the reporting category by itself does not establish legal or contractual responsibility, the report can provide only information about which party was estimated to be in control of the situation when the transport event occurred. This code category breaks down as follows:

HAULIER/CARRIER (CODE H)
The actions of his personnel interfering in the transport process, the performance of his equipment and the services delivered by his subcontractors and also of all the intermodal connections he used in the transport.
Examples: the driver misbehaved at the loading site; the vehicle broke down on the way to the delivery point.
SHIPPER (CODE S)
Controls the order and the documentation process, supervises loading site activities and his personnel interfering in the transport order.
Examples: the instructions given for the equipment were not adequate; the documents were not correct.
FINAL CUSTOMER (CODE C)
In control of the delivery point activities and the personnel assigned to the unloading. This can be at the customer’s site but also at the assigned terminal or warehouse where delivery takes place.
Examples: the operator of the unloading site is not present; there is an unsafe condition at the unloading site; the unloading cannot take place at agreed times due to congestion at the unloading bay.
BEYOND ANYONE’S CONTROL (CODE X)
Conditions where control possibilities from the involved parties are totally eliminated by external events out of their control and only when these happen without warning and the involved parties exerting control (carriers, shippers, final customers) are not reasonably able to develop alternate plans.
Examples: extreme sudden weather conditions prevented transport; unannounced strikes occurred on the way to the delivery point; unexpected excessive delays at customs; traffic accident not caused by the driver which blocks the road completely; suicide happened on the rail corridor where goods are transported; earthquake destroys unloading site.

5.3 Mode of transport

The code category “mode of transport” is specified further as "road" and "intermodal". Under "intermodal" is reported all events, including the road legs of an intermodal journey. This allows the hauliers to report accurately the information on non conformance events per selected transport mode.

5.4 Order type

The code category “order type” is specified further as normal order and rush order. The normal transport order is given to the carrier within the contractual order lead-time that has been agreed with the shipper and his customer. A rush order is a transport order that is not within the contractual agreed order lead-time. Circumstances of the order acceptance are different and the risk for events is higher, however expected customer’s requirements remain the same.

5.5 When did the event occur?

Each transport has a time line where the event can be situated. This code category is further specified and broken down as follows:

BEFORE LOADING (CODE B)
Before loading covers the events in the transport order generation and order administration. Before loading will also cover these events from the receipt of the transport order by the carrier until he arrives at the site entrance of the loading point.
Examples: a transport order was issued and was cancelled. An incorrect order number was communicated to the carrier. An EDI transmission got lost. The transport order contained wrong date, wrong quantities, etc. The carrier incurred a delay before arriving at the loading point due to congestion at the cleaning station or in traffic.
DURING LOADING (CODE L)
Events that happen between arrival of the carrier to pick up the goods at the loading point and the moment he leaves the loading site are reported under this code.
Examples: the driver did not have his required PPE with him; equipment was refused as not fit for purpose; a spill happened.
DURING TRANSIT (CODE T)
Events that occur after the goods have left the loading point and before they reach the place of discharge as well as between two (un)loading points are reported under this code.
Examples: a delay occurred because there was traffic congestion; a problem occurred at customs; the truck broke down on the road.
DURING DELIVERY (CODE D)
Events occurring between the arrival by the carrier at the unloading premises and his departure from the premises after discharge are recorded under this code.
Examples: seal was compromised; an incident such as a crossover took place; driver fell from truck.
AFTER DELIVERY (CODE A)
Events happening after the truck or transport unit has left the unloading point and before another transport order has been assigned. This code is only relevant for dedicated equipment, such as fuel and gas transports.
Examples: breakdown takes place whilst the truck is being relocated after delivery to the depot.

5.6 Customer complaint

In this code category, the haulier can report the apparent reason underlying the event causing a customer complaint. When this is the case, the information can be transmitted at a later time, after the haulier received from the shipper the information and did his internal investigation for the apparent reason.

5.7 Why did it occur? (apparent reason of the event)

In this code category, the carrier will report the apparent reason underlying the event.

Alphabetical list of the apparent reasons of the transport event and their scope:

N°	Description	Scope
1	Breakdown	Equipment malfunction: vehicle, accessories, (un)loading equipment (if SHE incident: report as equipment accident)
2	Cancellation	Transport order is revoked by shipper or refused by haulier (only before loading)
3	Cleaning station	Event disrupting or impacting the transport order is caused at the cleaning station
4	Cleanliness/not fit	Equipment incorrectly or insufficiently cleaned or too wet, previous load incompatible, equipment not fit (e.g. unloading hoses are not clean)
5	Communications/instructions	Misunderstanding or error in transmission of information between parties: such as someone forgot to say something; language problems; incorrect or incomplete delivery date instructions; delivery date as instructed
6	Congestion in traffic	Disruption of the transport order due to heavy traffic or a traffic accident (not one’s own accident, which is reported as equipment accident)
7	Congestion of bays	Waiting lines at (un)loading bays of shipper (incl. bays managed by third parties on behalf of the shipper) or customer (in some rare cases the haulier himself if he manages the (un)loading bays)
8	Crossover	Product loaded or unloaded in wrong tank/compartment/ storage tank
9	Documents missing/IT failure	Disruption due to documents not ready, disappeared or stolen, due to IT break down
10	Equipment accident or malfunction	(Traffic) accident with own equipment of haulier or intermodal operator or an equipment malfunction
11	Force of nature	Sudden natural phenomenon disturbing transport order such as weather, mudflows, avalanches, earthquakes, stone falls, storms
12	Incorrect/not conform	Date & time, equipment, accessories, documentation, quantities are not corresponding to what was